Arch LinuxでWi-Fi接続をしてみよう
Arch Linuxではインストールメディアや復旧用につかえるisoイメージがダウンロードできます。Archをインストールするときにダウンロードするやつです。
今回はそのArch Linuxインストールメディア環境下でWi-Fi接続に挑戦してみました。
有線だとほとんど設定いらずで接続できますが、Wi-Fi接続は知識が薄い@MINOには難敵でした…。
たとえば@MINOはルータが居間にあり、作業部屋にはLANケーブルを這わせていないので、Wi-Fi接続する必要があります。
居間に行けやと言われればそれまでですが、有線が使えない状況や使いにくい状況もあるかと思いますので、Wi-Fi接続設定の習熟は決して無駄では無いと思っています。
LANケーブル探さなくて済みますし、見つけたLANケーブルのツメが折れていて発狂しそうになることも無くなります。
今回の記事ではWi-Fi接続と書いていますが、無線LAN接続、ワイヤレス設定などと同義です。（ですよね？）
ArchWikiにも推奨されているように、手動でWi-Fi接続に挑戦しています。
今回も大いにハマりましたので、顛末をお楽しみください。
環境について
インストールメディアとArch Linuxインストール後の初期状態との違い
先にも説明しましたとおり、Arch Linuxのインストールメディア（ISOイメージ）をDVDに焼いて起動です。
注意点としては、このインストールメディアに収録されているアプリケーションやコマンドは、Arch Linuxをインストールしたときに初期状態で含まれるアプリケーションやコマンドと大分ラインナップが違うことです。
インストールメディアではさまざまな設定が行えるように、たくさんのアプリケーションやコマンドが収録されており、高機能です。
ですからArch Linuxインストール後の初期状態ではまだ入っていないアプリケーションやコマンドを使うことになります。
このインストールメディアに収録されているアプリケーションやコマンドはある程度先進的なものですので、ここで使い方に慣れておき、Arch Linuxインストール後に導入するという流れがいいのではないでしょうか？
今回のデバイス環境
@MINOが使用しているのはNECのAtermWR9500Nというブロードバンドルータです。普通の家庭用ルータなので特別な機能はありません。
AtermWR9500Nには多くの家庭用ルータと同じようにDHCPサーバ機能がありますので、家庭内LANにおいてはルータのDHCPサーバ(機能）からIPを払い出してもらうことになっています。
またクライアントデバイスはノートパソコンにデフォルトで付いていたAzureWaveのAW-NE766(Realtek RTL8723BEを搭載した PCIe Wireless Network Adapterです)を使っています。カニさんマークチップの普通のWi-Fi子機ですね。
クライアントデバイスは補足的にもう一つ使いました。USBドングルタイプのPLANEX GW-USValue-EZ（Realtek RTL8188CUS）です。
- ブロードバンドルータ（親機） AtermWR9500N
- Wi-FiクライアントデバイスPCIe（子機） AzureWave AW-NE766(Realtek RTL8723BE)
- Wi-FiクライアントデバイスUSB (子機） PLANEX GW-USValue-EZ（Realtek RTL8188CUS）
Wi-Fi接続に挑戦する
基本的にはArchWikiのワイヤレス設定を参考に進めました。
デバイスの確認
まずデバイスを確認します。
PCIe機器の確認をする
PCIe機器の場合は、以下のコマンドで確認できました。
root@archiso lspci -k
~~~~~~~~~~~~
~~~~~~~~~~~~
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter
Subsystem: Realtek Semiconductor Co., Ltd. Device b729
Kernel driver in use: rtl8723be
Kernel modules: rtl8723be
~~~~~~~~~~~~
~~~~~~~~~~~~ずらっといろいろ出力されると思いますが、その中に「Wireless」的な記述のある出力があると思います。@MINOの環境では以上のように出力されました。
USB機器の確認をする場合
もしUSB機器の場合は以下です。
root@archiso lsusb -v
~~~~~~~~~~~~
~~~~~~~~~~~~
Bus 003 Device 006: ID 2019:ed17 PLANEX GW-USValue-EZ 802.11n Wireless Adapter [Realtek RTL8188CUS]
Couldn't open device, some information will be missing
~~~~~~~~~~~~
~~~~~~~~~~~~デバイスが認識されていない？
もしデバイスがうまく認識されていないようならdmesgを使って、詳細情報を確認してみます。
認識およびファームウェア読み込み成功しているとdmesgで以下のような出力があるはずです。
~~~~~~~~~~~~
[ 4.981722] rtl8723be: Using firmware rtlwifi/rtl8723befw.bin
~~~~~~~~~~~~~~~~~~~~~~~~~
[ 4171.013661] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
~~~~~~~~~~~~上段のrtl8723beはlspci -kで確認できた「Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter」のことです。
下段のrtl8192cuはlsusb -vで確認できた「PLANEX GW-USValue-EZ 802.11n Wireless Adapter [Realtek RTL8188CUS]」のことです。
もしファームウェアの読み込みに失敗していると以下のようなメッセージが出てるかもしれません。
~~~~~~~~~~~~~
~~~~~~~~~~~~~
[ 102.285885] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[ 102.285915] usb 1-2: firmware: failed to load rtlwifi/rtl8192cufw_TMSC.bin (-2)
[ 102.285921] usb 1-2: Direct firmware load failed with error -2
[ 102.285925] usb 1-2: Falling back to user helper
[ 102.289818] usb 1-2: firmware: failed to load rtlwifi/rtl8192cufw.bin (-2)
[ 102.289826] usb 1-2: Direct firmware load failed with error -2
[ 102.289830] usb 1-2: Falling back to user helper
~~~~~~~~~~~~~
~~~~~~~~~~~~~これはDebian/Jassieにて「PLANEX GW-USValue-EZ」は認識されたが（ドライバは読み込まれたが）、ファームウェアをインストールできておらず、読み込みに失敗したときの出力です。
もしファームウェアの読み込みに失敗するとArchLinuxインストールメディア環境下でも同じような出力が出るのではないかと思います。
特にすごく古い機器などは使えない場合もあるかもしれません。
インストールメディア環境下でもかなりの数のデバイスが認識・使用可能の状態になるようですが、もしトラブるようならdmesgの確認及び、ArchWikiのワイヤレス設定-トラブルシューティングを確認してみてください。
今回は@MINOにとってはめずらしく、デバイスがきちんと認識されており、ドライバ・ファームウエアともにきちんと読み込みがされていました。いつもなら大抵デバイスの認識関係でトラブるですが、その点では楽でした。最近のLinuxのデバイス認識にバンザイ！！
デバイスのロックの確認
Windowsとのデュアルブート時などで、Wi-Fiデバイスがロックされており、使えなくなっている場合があります。
Wi-Fiデバイスは常に電波を探したりしているので、それなりに電力を食うのだそうです。
使わないときには電源を切っていたほうが省電力につながり、ノートならバッテリー持続にも影響してくるかもしれません。
そのためにロックする場合があるそうです。
ロックには、ソフトウェアでロック（softblock）、物理スイッチでロック(hardblock）の2種類があるそうです。
Windowsをインストールした（起動させていた）パソコンでは、電源を切った後でもsoftblockされている場合があります。（Linux起動機でもロックされている場合はあります）
そのため、ドライバ・ファームウェアが読み込まれていても、いっこうにデバイスが使えないという悲しい状態になるかもしれません。
ですので、ロック状況を確認しておきましょう。
ロックされているか確認する
コマンドは以下です。
root@archiso rfkill list
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
2: phy1: Wireless LAN
Soft blocked: no
Hard blocked: no
Wi-Fi機器が複数あると、複数の出力があると思います。Bluetooth機器も出力されるようですね。
通常は機器は一つだと思いますが、もし複数の機器をつなげている場合は、「phy0」（物理機器を表す識別番号）等の名前で機器を識別してください。
インターフェースとの対応状況の確認
下記のコマンドで物理機器識別の名前とインターフェース識別の名前の対応がわかりますので、複数機器を繋げている方は機器の特定のために確認してみてください。
root@archiso iw dev
phy#1
Interface wlp0s20u3
ifindex 5
wdev 0x100000001
addr 182:25:45:ea:xx:xx
type managed
txpower 20.00 dBm
phy#0
Interface wlp3s0
ifindex 3
wdev 0x1
addr 74:df:bf:a7:xx:xx
type managed
channel 7 (2442 MHz), width: 20 MHz, center1: 2442 MHz
txpower 20.00 dBm
ロックされていたら…
もしsoftblockされていると「soft blocked」が「yes」になっているかと思います。そうするとデバイスがロックされていることになります。
以下はsoftblockされている場合の出力です。
root@archiso rfkill list
0: phy0: Wireless LAN
Soft blocked: yes
Hard blocked: no
ロックを解除するには以下のコマンドを使います。
root@archiso rfkill unblock [id][id]はrfkill listで出力された、phyの前の数字の0のことです。複数機器がある場合は0、1、2と増えますので、必要な機器を指定してください。
もし物理スイッチがOFF（つまりhardblockがyesになっている場合）になっている際は、物理スイッチをONにしてください。@MINOの環境では物理スイッチは無いので、物理スイッチがOFFになっている状態は確認できませんでした。
「soft blocked」「hard blocked」がどちらも「no」になっていればロックが解除されている状態になり、機器が使えるようになるはずです。
インターフェースを立ち上げる
ネットワーク関係ではコマンドがいくつか存在しますが、最近ではiproute2を使うことが推奨されているそうなので、今回はiproute2に含まれるipコマンドやiwコマンドを使って作業を行っていきます。
従来のifconfig等を含むnet-toolsは非推奨になったそうで次第に使われなくなっていくようです。
さて、大抵のデバイスでは接続時にインターフェースが有効になっているかと思うのですが、稀にインターフェースが無効になっている場合もあります。
先程のロックの件などで使用可能状態になっていなかった、デバイスの固有の挙動等の理由があるようです。
@MINOの環境ではさっそく無効になってやがりました。
そこでインターフェースが有効になっているかどうかを確かめます。
確認は以下のコマンドでできます。
root@archiso ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp4s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether 80:fa:5b:32:4d:cf brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
link/ether 74:df:bf:a7:xx:xx brd ff:ff:ff:ff:ff:ff
8: wlp0s20u3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
link/ether 82:25:45:ea:xx:xx brd ff:ff:ff:ff:ff:ffいくつかのインターフェースの詳細が出力されます。
インターフェース名がちょっと複雑じゃない？
Archインストールメディア環境下では従来のwlan0のようなインターフェース名は使われず、リネームされてちょっとだけ複雑なインターフェース名になっています。
この命名方法を“Predictable Network Interface Names”というのだそうです。
従来のwlan0のような命名は機器と結びついておらず、早く認識された方からwlan0、wlan1といったふうにつけられるようです。
これだとPCIe機器がwlan0に割り当たるのか、はたまたUSB機器のほうがwlan0に割り当たるのかが「確実にはわからない」のだそうです。
ですので、インターフェース名で機器を特定できるような命名方法になったのだそうです。
これはデバイスを管理するudevの機能です。udevはsystemdの一部なので、systemdを採用しているディストリビューションでは”Predictable Network Interface Names”が主流になっていくのだと思いますので、慣れたほうがいいかもしれません。
有効・無効の見分け方
インターフェースが有効になっている場合、インターフェース名の後ろの<BROADCAST,MULTICAST,UP,LOWER_UP>の部分にUPという表記があるはずです。
もし無効なら<BROADCAST,MULTICAST>のようにUPはありません。後ろの方に紛らわしいUPとかDOWNとかがありますが、関係ないですので無視しちゃってください。
以下はわざとUSB機器の方を無効化して出力したものです。違いがおわかりいただけるかと思います。
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
link/ether 74:df:bf:a7:xx:xx brd ff:ff:ff:ff:ff:ff
8: wlp0s20u3: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
link/ether 82:25:45:ea:xx:xx brd ff:ff:ff:ff:ff:ffインターフェースを有効にする
もしインターフェースが無効になっているようなら有効にしないといけません。以下のコマンドで有効化できます。
root@archiso ip link set [interface] up[interface]は目的のインターフェース名を入れてください。
@MINOの環境で先程の無効にしたインターフェースを有効化するには以下のようになりますよ。
root@archiso ip link set wlp0s20u3 up実際に接続してみる
さんざんっぱら確認作業をしてきましたので、もうインターフェース名はおわかりかとは思いますが、一応iwコマンドでも確認しておきます。さっきも説明しましたが再度です。
root@archiso iw dev
phy#1
Interface wlp0s20u3
ifindex 5
wdev 0x100000001
addr 182:25:45:ea:xx:xx
type managed
txpower 20.00 dBm
phy#0
Interface wlp3s0
ifindex 3
wdev 0x1
addr 74:df:bf:a7:xx:xx
type managed
channel 7 (2442 MHz), width: 20 MHz, center1: 2442 MHz
txpower 20.00 dBm
これでインターフェース名がわかります。iwはワイヤレス環境用のコマンドなので、ipのようにすべてのインターフェースは表示されません。ワイヤレスインターフェースのみ表示されます。便利ですね。
接続方式の確認
さて今度はルータに関して調べる必要があります。ルータの認証がどの方式に対応しているかです。
最近の家庭用無線ルータであればほとんど間違いなくWPAかWPA2に対応しているかと思います。WEPはすでに脆弱性が指摘されており使うべきではないとされています。
しかし困ったことに、古めのルータを使っていたりするとWPAに対応していなかったりします。買い替えた方がいいかとは思いますが、そこはそれ。
またもちろんクライアント側でWEPにしか対応していない場合もあるかもしれません。
ですので家庭用無線ルータとの接続は、「WEPでの接続」、「WPA/WPA2での接続」の2種類が可能性としてあります。
WPA/WPA2もパーソナルとエンタープライズという2種が存在していますが、エンタープライズは別途認証サーバを用意する大規模ネットワーク向け（企業とか）の方式なのでここでは触れません（わからなすぎて触れられません）。
Wi-Fiのこの接続認証の方式名が結構厄介で、いろいろな呼び名があったり、暗号化アルゴリズム名や暗号化方式とごっちゃになってしまったりします。
ですのでちょっと表にまとめてみました。
| 規格名 | 暗号化方式 | 暗号化アルゴリズム |
|---|---|---|
| WEP | WEP | RC4 |
| WPA | TKIP | RC4 |
| WPA2 | CCMP | AES |
WEPはそのまま規格名でもあり、暗号化方式名でもあります。一方WPAとWPA2では暗号化方式および暗号化アルゴリズムが異なります。
またWPAでは任意でCCMP/AESを採用できますし、WPA2でも任意でTKIP/RC4を採用したりできます。
このためいろいろな規格の書き方が存在しています（と思います）。
@MINOが使っているルータでは以下のような設定が用意されていました。
- WEP
- WPA/WPA2-PSK(TKIP)
- WPA/WPA2-PSK(AES)
- WPA-PSK(TKIP)
- WPA-PSK(AES)
- WPA2-PSK(TKIP)
- WPA2-PSK(AES)
これを見ると不思議に思うのが、暗号化方式であるTKIPと暗号化アルゴリズムであるAESを呼び名につかっている点です。
だって暗号化方式を使ってWPA-PSK(TKIP)とかとするなら、WPA-PSK(CCMP）とするべきなんじゃないだろか？
なんでこんなふうな呼び方になったんですかね？混乱させようとする気まんまんじゃないですか…。
PSKってなに？
PSK (Pre-Shared Key)とはプリシェアードキーと呼ばれ、事前共有鍵などと訳されます。
先程「WPA/WPA2にはパーソナルとエンタープライズがある」と説明しましたが、パーソナルではこのPSKを使って認証します。
鍵を使った認証では共有鍵を使う必要があり、共有鍵を秘密裏に通信相手同士が持つことが必要になります。
しかし共有鍵が見られてしまうと侵入されてしまうのでどうしようもありません。まさか平文で送るわけにも行かず、共有鍵を送るための通信を暗号化するための共有鍵が必要でさらに…と無限ループになってしまいます。
そこでWPA/WPA2パーソナルでは、ルータのウラ面などにキー（セキュリティキー、ネットワークキー、パスフレーズ、パスワード、暗号化キーなどという言い方もします）が書いてあり、このキーをもとに生成された共通鍵（つまりPSK）を使って認証を行えるようになっています。
このキーを知られてしまうとネットワークに入られてしまいますが、ルータを直に見ないとバレないものではあるので、家庭用としては手軽に扱える共有鍵として使えます。
物理的に見られない＝セキュリティとしているということですね。
もちろんデフォルトのキーを変更することが可能なので、気になる人は変更してルータを見られてもバレないようにしておくのも手です。
さて、@MINOのルータでのデフォルト設定ではWPA/WPA2-PSK(AES)という設定となっています。
これはWi-FiクライアントがWPAに対応しているかWPA2対応しているかで自動的に適切な方を選択する設定です。
WPA/WPA2-PSK(AES)という規格があるのではなくルータの機能としての呼び名なのだと思います。
接続の確認とアクセスポイントの検索
まず、ルータのアクセスポイント名であるSSIDと認証に用いるキーを確認しておいてください。
@MINOのルータでは背面に書いてありましたよ。
すでに接続したいアクセスポイント（のSSID)がわかっているので必要は無いかもしれませんが、一応アクセスポイントの検索の方法を書いておきます。
以下のコマンドで検索します。
root@archiso iw dev wlan0s3 scan
BSS 10:xx:xx:e2:xx:76(on wlp3s0) -- associated
TSF: 1841290409568 usec (21d, 07:28:10)
freq: 2442
beacon interval: 100 TUs
capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431)
signal: -56.00 dBm
last seen: 30 ms ago
Information elements from Probe Response frame:
SSID: aterm-46xxdb-g
Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
DS Parameter set: channel 7
Country: JP Environment: Indoor/Outdoor
Channels [1 - 13] @ 20 dBm
ERP:
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: PSK
* Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000)
Extended supported rates: 24.0 36.0 48.0 54.0
HT capabilities:
Capabilities: 0x11ee
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: No restriction (0x00)
HT RX MCS rate indexes supported: 0-15
HT TX MCS rate indexes are undefined
HT operation:
* primary channel: 7
* secondary channel offset: no secondary
* STA channel width: 20 MHz
* RIFS: 1
* HT protection: no
* non-GF present: 1
* OBSS non-GF present: 0
* dual beacon: 0
* dual CTS protection: 0
* STBC beacon: 0
* L-SIG TXOP Prot: 0
* PCO active: 0
* PCO phase: 0
Overlapping BSS scan params:
* passive dwell: 20 TUs
* active dwell: 10 TUs
* channel width trigger scan interval: 300 s
* scan passive total per channel: 200 TUs
* scan active total per channel: 20 TUs
* BSS width channel transition delay factor: 5
* OBSS Scan Activity Threshold: 0.25 %
Extended capabilities: HT Information Exchange Supported
WPA: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: PSK
WMM: * Parameter version 1
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 3008 usec
* VO: CW 3-7, AIFSN 2, TXOP 1504 usec
WPS: * Version: 1.0
* Wi-Fi Protected Setup State: 2 (Configured)
* AP setup locked: 0x00
* Response Type: 3 (AP)
* UUID: 09182736-xxxx-6372-xxxx-106682e21175
* Manufacturer: NEC Platforms, Ltd.
* Model:
* Model Number:
* Serial Number:
* Primary Device Type: 6-0050f204-1
* Device name: WR9500N
* Config methods: Ethernet, Label, PBC
* RF Bands: 0x1
アクセスポイントは電波が届くご近所さんのものも検索されます。結構大量に見つかるかもしれません。
上記は自分のルータの結果だけを掲載したものです（一部伏せ字にしています）が、かなりの分量の情報が出力されますので、閲覧するのが大変かもしれません。適切にgrepなどを使うことをおすすめします。
さてお使いのルータのSSIDは見つかりましたでしょうか？
今回では特に詳しい情報を使うことはしませんのでSSIDだけ確認してください。
@MINOのルータではデフォルトでは「aterm-xxxxxxxx」といったようなSSIDになっています。
一応どの暗号化方式が有効になっているか確認すると、RSNがWPA2のことを表しています。
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: PSK
* Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000)またWPAがそのままWPAを表しています。
WPA: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: PSKWPA/WPA2どちらでも接続・認証できることがわかります。
接続確認について
ArchLinuxインストールメディア環境下では無線接続が勝手に疎通することはありませんので、現時点で接続が成功しているはずはないのですが、Wi-Fi接続されているかどうかの確認は以下のコマンドで行います。
root@archiso iw dev wlan0s3 link
Not connected.接続されていない場合は上記のような出力になります。
ハマった話から先に…
@MINOはArchWikiをあんまりよく読まずにiwコマンドで接続を試行してしまいました。何度も何度も試してみるがいっこうに接続できず…なんでだろうと途方にくれたものです。
先に恥を暴露すると「WPA/WPA2の場合はiwコマンドは使えなかった」ということでした。
これはいろいろ調べた結果、以下のサイトにも明確に回答がありました。
AskUbuntu “How do I connect to a WPA wifi network using the command line?”
曰く、
“iw (list/config) can only handle WEP.（iwはWEPしか扱えないよ）”
だそうです。先にこの記述を見つければよかったんですが…。
しかしなぜつながりもしないiwでそんなにもハマり続けたのか。
それは以下のような理由からです。
なぜハマり続けたのか
iwコマンドは以下のようにSSID名とキーを指定して接続します。
iw dev wlan0 connect your_essid key 0:your_key@MINOの環境では…
iw dev wlan0 connect aterm-46xxdb-g key 0:06xxfffxxxxxxといった感じになります。（もちろんキーがWPAのものなので認証はされませんが）
このコマンドを実行したあとに、先程説明した接続確認のコマンドを実行してみると…
root@archiso iw dev wlan3s0 link
Connected to 10:xx:xx:e2:xx:76 (on wlp3s0)
SSID: aterm-46xxdb-g
freq: 2442
RX: 11657776 bytes (60578 packets)
TX: 2466105 bytes (7534 packets)
signal: -58 dBm
tx bitrate: 72.2 MBit/s MCS 7 short GI
bss flags: short-preamble short-slot-time
dtim period: 1
beacon int: 100
接続されていると出るんですよね。
しかしこの後の作業として、ipの設定（dhcpcdでipを与える）が全くうまく行かず、どうやってもネット疎通が確認できません。
ルータには接続されているのだから、dhcpcdなどの不具合だろうと思い、何時間もあーでもないこーでもないと右往左往していました。
罠にハマっていることに気づく
しかし、たまたま作業中にiw connectでキーを間違って打ってエンターを押してしまったのがきっかけで、なんだかおかしいことに気が付きました。
ふむ？なにもエラーが返ってこない。あれ？キー間違っているんだぞ？なんでエラーにならんのだ？
接続状況を確認してみます。
root@archiso iw dev wls3s0 link
Connected to 10:xx:xx:e2:xx:76 (on wlp3s0)
SSID: aterm-46xxdb-g
freq: 2442
RX: 11657776 bytes (60578 packets)
TX: 2466105 bytes (7534 packets)
signal: -58 dBm
tx bitrate: 72.2 MBit/s MCS 7 short GI
bss flags: short-preamble short-slot-time
dtim period: 1
beacon int: 100
あれ？つながっちゃっているぞ？
もしかしてルータの設定がザルになっているのか？キーなしで接続できるようにした記憶はないのですが…。
あせってルータの設定をくまなく確認しましたが、キーは有効になっています。認証なしには通信はできません。
どうしたことだ？
接続と認証について
いろいろ調べているうちにだんだんと意味が分かってきました。
そもそもiw linkで出力されるこの状態を「認証成功」という風に認識してはいけないようです。
あくまでも「接続には成功している」という意味なのだそうです。
接続成功と認証成功を同じような意味に感じていた@MINOにとっては晴天の霹靂でした。
しかし冷静に考えてみれば、認証云々の前に、認証過程のやり取りをするために接続が繋がっていなと話になりませんよね。
後述しますが、WPA/WPA2では4ウエイハンドシェイクという方法をもって認証をおこなうのだそうで、その通信を行うためには認証のない状態での接続が必要です。
セキュリティ上の配慮
たとえば、脆弱性の一つの要素として「そのパスワードは使えません」と応答してしまうことがあげられます。
パスワードが間違っていることがわかると再試行するべきことがわかってしまいます。つまり不正侵入の足がかりを作ってしまうことになります。
このことに関してはこちらのサイトさんが詳しく書いていらっしゃいます。
サイレックス・テクノロジー 株式会社 WiFiの接続手続きのはなし
接続が成功したかどうかは応答しないというのは一見とても不親切に感じますが、セキュリティの見地からは正しい動作だといえますよね。
（後述するwpa_cliを使った接続で4ウエイハンドシェイクの失敗（FAIL）が表示される場面を確認できたので、内部的には失敗判定はなされているようですが、それを外に見せないということなんでしょうか？）
dmesgにてiw connectでの接続試行に該当する出力を確認してみましたが、接続が「失敗した」ことは現れないようです。
[ 817.428984] rtl8192cu 3-3:1.0 wlp0s20u3: disabling HT/VHT due to WEP/TKIP use
[ 817.430049] wlp0s20u3: associate with 10:xx:xx:e2:xx:76 (try 1/3)
[ 817.454810] wlp0s20u3: RX AssocResp from 10:xx:xx:e2:xx:76 (capab=0x431 status=0 aid=5)
[ 817.455852] wlp0s20u3: associated
[ 817.477392] wlp0s20u3: deauthenticating from 10:xx:xx:e2:xx:76 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 819.748009] wlp0s20u3: authenticate with 10:xx:xx:e2:xx:76
[ 819.758691] wlp0s20u3: send auth to 10:xx:xx:e2:xx:76 (try 1/3)
[ 819.859963] wlp0s20u3: send auth to 10:xx:xx:e2:xx:76 (try 2/3)
[ 819.862809] wlp0s20u3: authenticated最後に「authenticated」がありますが、これは「認証した」という意味です（よね？）失敗しても成功してもこれ出るみたいですね。
実際には出力からわかるように本来はWPAでの認証なのですが、WEPで認証しようとしていますから失敗しているはずなんです。
WPA/WPA2の場合このauthenticateの手続きが形骸化しており、先も書きましたが4ウエイハンドシェイクという方法で認証をするそうです。
WPEではこの4ウエイハンドシェイクが存在しないので認証ができません。iwでは4ウエイハンドシェイクの手続きに進まないということですね。
ですのでアクセスポイントには接続はされているが認証はされていないという浮いた状態になっていたのですね。通路にはいるけど入り口の扉は閉まっている感じでしょうか？
今回の事例は。そのへんの事情を勘違いして（というか知らずに）ずっとiwで接続を試みていたということになるのだと思います。
頭悪すぎですね。
WPA/WPA2の場合はWPA supplicant
さて、iwコマンドはWEP方式を用いるときに使うものだということがわかりました。
WPA/WPA2では別途、WPA supplicantというコマンドを使います。
ArchWikiにはiwコマンドの説明の見出しに「WEP」って書いてあるんですけどね…。なんで見逃したんだろ…。
ともあれ、WPA/WPA2ではWPA supplicant、WEPではiwを使うということですね。（WPA supplicantでWEPでの接続もできるそうですが今回はやりません）
WPA supplicantとwpa_cliを使って接続
WPA supplicantとインタラクティブ接続マネージャのwpa_cliはArchインストールメディアに収録されていますので使えます。Arch Linuxインストール後の初期状態では入っていませんのでご注意ください。
ここからはほとんどArchWikiの内容そのまんまになりますが、一応書いておきたいと思います。
まずは対話的に接続をする方法です。
設定ファイルを作る
まず接続するための準備として設定ファイルを作ります。
以下のディレクトリに任意の名前のconfファイルを作ります。ここではwifi.confにしてみました。
/etc/wpa_supplicant/wifi.conf最低限の設定でよいそうなのでこのファイルにviなどで以下のような内容を記述します。
ctrl_interface=/run/wpa_supplicant
update_config=1この設定ではインターフェースの指定（ctrl_interface）と、confファイルの上書き編集を許可しています（update_config）。
例では/run/wpa_supplicantとしましたが、/var/run/wpa_supplicantでもいいようです。
どうもvarをマウントする順番の関係で/var/runではなく/runを使った方がいいようですが、@MINOの環境では違いがわかりませんでした。
多くの場合このディレクトリには稼働しているプロセスなどのPIDが入っているそうです。
今回の場合はデバイスとの通信のために用いるソケットの指定が目的です。
wpa_supplicantが起動すると指定したインターフェースのUnixドメインソケットが/run/wpa_supplicantディレクトリに現れます。
/run/wpa_supplicant/wlp3s0このソケットを使ってwpa_supplicantは接続を拵えていきます。
またupdate_configはこの後使うwpa_cliがconfファイルに設定を書き足してくれるので、それを許可する記述です。これを1にしておかないとwpa_cliで設定した接続情報がconfファイルに反映されないので悲しくなります。
ディスク起動なので、実際にはストレージに保存されるわけではありませんが、電源を切るまではメモリにこのファイルが存在しますので、ご安心ください。
wpa_supplicantを起動
さてファイルができたらこのファイルを元にwpa_supplicantを起動します。
コマンドとしては以下になります。
wpa_supplicant -B -i [interface] -c /etc/wpa_supplicant/wifi.conf[interface] には接続に使うインターフェースを指定します。Bオプションはバックグラウンド起動です。フォアグラウンドだとターミナルが占拠されてしまうのでバックグラウンドで起動してください。
iオプションはインターフェース指定、cオプションは設定ファイルの指定です。
@MINOの場合は実際には以下のようになります。
root@archiso wpa_supplicant -B -i wlp3s0 -c /etc/wpa_supplicant/wifi.confこれで起動が成功すると以下のような出力があります。
Successfully initialized wpa_supplicantもし起動に失敗するとヘルプの内容が出力されますので、インターフェース名などが間違っていないか確認してみてください。
wpa_cliで対話設定
次にwpa_cliを起動します。wpa_cliは対話的にWi-Fi接続を設定できるコマンドです。
設定した接続情報は先程作ったwifi.confに追加保存することができます。
最初の接続だけwpa_cliでやっておけば後は接続情報をつかってwpa_supplicantのみで接続ができるので便利です。
wpa_cliを起動
wpa_cliを起動するとプロンプトが以下のようになります。
Copyright (c) 2004-2016, Jouni Malinen and contributors
This software may be distributed under the terms of the BSD license.
See README for more details.
Interactive mode
Selected interface "wlp3s0"
>
これで対話的に接続が行えます。
アクセスポイントの情報を得る
すでにSSIDはわかっているかと思いますが、このwpa_cliからもアクセスポイント（の情報）を検索することが可能です。
アクセスポイントを検索するには以下のようにします。
>scan検索結果を確認するには以下のようにします。
>scan_resultsこれでアクセスポイントの検索結果がずらっと出力されます。ここからでもSSIDを確認できます。
接続情報を作る
次に接続情報を新規作成します。
>add_network 0
0
>
これで0番の接続情報が出来上がりました。
SSIDの指定
今度はSSIDを設定します。ssidの後ろは各位のssid名を打ち込んでください。@MINOの環境では以下のようになります。
>set_network 0 ssid "aterm-46xxdb-g"
OK
>
ssid名は””で囲う必要があります。囲わないとFAILとなり設定が失敗します。
キーの指定
キーを設定します。pskの後ろは各位のキーを打ち込んでください。@MINOの環境では以下のようになります（キーは伏せ字にしています）
>set_network 0 psk "06xxfffxxxxxx"
OK
>
ここもキーを””で囲う必要があります。
接続実行
これで接続情報が入りましたので接続を実行します。接続するには以下のようにします。
>enable_network 0
OK
>
認証成功時の出力
接続・認証に成功すると以下のような出力が出ると思います。
〜〜〜〜〜〜
〜〜〜〜〜〜
WPA: Key negtiation completed with 10:xx:xx:e2:xx:76 [PTK=CCMP GTK=CCMP]
〜〜〜〜〜〜
〜〜〜〜〜〜認証失敗時の出力
もし認証が失敗すると以下のような出力がでます。
〜〜〜〜〜〜
〜〜〜〜〜〜
WPA: 4Way-Handshake failed - pre-sherd key may be incorrect
〜〜〜〜〜〜
〜〜〜〜〜〜先程説明した4ウエイハンドシェイクが失敗した旨の出力だということがわかりますね。
この状態も接続はできたが認証されていないという状態になります。
もしSSIDが間違っているとそもそも接続自体がされません。
認証が失敗するのはキーの入力が間違っているからのはずです。
再度set_network 0 pskにてキーを入れ直して、enable_networkしてください。
ややタイムラグが出るかもしれませんが、新しいキーで認証が試行されるはずです。
接続情報を保存する
ちゃんと接続・認証に成功したら設定を保存しておきましょう。
保存するには以下のようにします。
>save_config
OK
>
これで先程作ったwifi.confにアクセスポイントの接続情報が追加されます。
ファイルを確認してみると以下のようになっているかと思います。最低これだけあれば接続できちゃうんですね。
ctrl_interface=/run/wpa_supplicant
update_config=1
network={
ssid="aterm-46xxdb-g"
psk="06xxfffxxxxxx"
}
接続情報を恒久的に保存する
復旧時などで何度も再起動をかけたりする場合、いちいち設定ファイルを作り直すのも面倒ですので、たとえばUSBメモリなどに保存しておく手もあります。
/etc/wpa_supplicant/以下にファイルが無いとだめなわけではないようですので、マウントしたUSBメモリなどにファイルを保存しておけば手間が省けます。
以下のようにしてUSBメモリをマウントしてファイルをUSBメモリに保存してください。（sdxデバイス名は各位の環境で違いますので適切な名前を指定してください）
root@archiso mount /dev/sdx1 /mntUSBメモリからのファイルを使う場合でもwpa_supplicantの起動の仕方は同じです。
root@archiso wpa_supplicant -B -i wlp3s0 -c /mnt/wifi.confこれでwpa_cliでの接続情報保存も恒久的にUSBメモリにのこりますので、なんどもやり直さなくて済みますね。
もしくは他のPCで接続設定ファイルを作っておいてそれを用いるという方法でもいいかもしれません。事前に用意しておくと復旧時に慌てなくていいですよ。
接続情報ファイルがあれば次回からはwpa_supplicantをそのファイルで起動するだけで接続が成功するはずです。（電波が弱いとか、ルータが落ちているとか無い限り）
wpa_passphraseを使う
wpa_passphraseはコマンドライン上で最低限の接続情報を作り出してくれる接続ヘルパーです。接続設定ファイルを用いないので、素早く接続するにはいいかもしれません。
平文でキーを扱わなくて済む
またこちらではキーをもとにPSKを作ってくれます。
以下のように実行すると…
root@archiso wpa_passphrase aterm-46xxdb-g 06xxfffxxxxxxこういった出力が得られます。
network={
ssid="aterm-46xxdb-g"
#psk="06xxfffxxxxxx"
psk=ca98e236627635727c78bfd87d468e70c812e772747f9433ade9e145bec269d1
}何やら長い文字列がpskとして出力されています。これはキーを元にして作ったPSKです。
これを用いることで平文でキーをファイルに書かなくて済みます。この場合は””で囲われれていないことに注意してください。
そして元のキーがコメントアウトされています。
キーを平文で書かない接続設定ファイルを作る
例えば先程のwifi.confにこの内容をリダイレクトして、pskを書き換えておけばセキュリティを確保することができます。
先程wap_cliによって情報が追記されたwifi.confから平文キーを排除するとしたら以下のようにします。
root@archiso wpa_passphrase aterm-46xxdb-g 06xxfffxxxxxx >> /mnt/wifi.conf これでwifi.confはこんな内容になりますので…
ctrl_interface=/run/wpa_supplicant
update_config=1
network={
ssid="aterm-46xxdb-g"
psk="06xxfffxxxxxx"
}
network={
ssid="aterm-46xxdb-g"
#psk="06xxfffxxxxxx"
psk=ca98e236627635727c78bfd87d468e70c812e772747f9433ade9e145bec269d1
}以下の様にコメントアウトされた元のキーとwpa_cliによって書き込まれた内容を消して保存します。
ctrl_interface=/run/wpa_supplicant
update_config=1
network={
ssid="aterm-46xxdb-g"
psk=ca98e236627635727c78bfd87d468e70c812e772747f9433ade9e145bec269d1
}もちろんwpa_cliを介さずに最初からwpa_passphraseをリダイレクトさせて接続情報ファイルを作るのもアリです（というかそっちのほうが早いと思います）
接続設定ファイルではもっといろんな項目を設定できますが、最低限ssidとpskがわかっていれば接続・認証が行なえます。
この最低限の状態だからと言って暗号化の強度が弱くなるということはありません。
IPを得る
接続・認証が成功したら最後にIPを得ます。
@MINOの環境ではルータがDHCPサーバとなっていますので、動的にIPを得るためdhcpクライアントであるdhcpcd（dhcpdじゃないよ）を使います。
Archインストールメディアにはdhcpcdと同じ働きをするdhcliantも収録されていますので、そちらを使い慣れている方は使ってみてください。
dhcpcdの場合では以下の様にします。
root@archiso dhcpcd wlp3s0成功すると得られたip等が表示されます。
疎通の確認
後はインターネットに出られるかをpingで確認します。
root@archiso ping google.co.jp
PING google.co.jp (216.58.199.227) 56(84) bytes of data.
64 bytes from kix05s02-in-f227.1e100.net (216.58.199.227): icmp_seq=1 ttl=48 time=532 ms
64 bytes from kix05s02-in-f227.1e100.net (216.58.199.227): icmp_seq=2 ttl=48 time=277 ms
64 bytes from kix05s02-in-f227.1e100.net (216.58.199.227): icmp_seq=5 ttl=48 time=126 ms
…………
………
……
これでWi-Fi接続が完了です。
まとめ
さて、かなり長い記事になってしまいましたが、Arch Linuxインストールメディア環境下でのWi-Fi接続について、ちょっとはお役に立てるでしょうか？
iwがwpaに使えないという事実を知るまで約3日かかりましたので、みなさんはそんな無駄な時間を過ごさないでください。
いやそんなの@MINOだけですかね…。
ともあれArch Linuxインストールメディアはいろいろ使えますので一枚焼いておいて損はないですよ〜。
